feat(profiling): real torch flame graphs - #18457
feat(profiling): real torch flame graphs#18457gh-worker-dd-mergequeue-cf854d[bot] merged 4 commits into
Conversation
This comment has been minimized.
This comment has been minimized.
BenchmarksBenchmark execution time: 2026-06-04 09:21:10 Comparing candidate commit 762fc42 in PR branch Found 0 performance improvements and 5 performance regressions! Performance is the same for 615 metrics, 10 unstable metrics. scenario:iastaspects-index_aspect
scenario:iastaspects-title_aspect
scenario:iastaspectsospath-ospathbasename_aspect
scenario:span-start
scenario:telemetryaddmetric-1-count-metric-1-times
|
762fc42 to
1e5f2f8
Compare
Codeowners resolved as |
f2928af to
2a99ff9
Compare
emmettbutler
left a comment
There was a problem hiding this comment.
release note looks good
@KowalskiThomas : |
Given that we don't officially support PyTorch in the Profiler (it's "experimental") I don't think adding a DoE benchmark for it is warranted at this point. We also probably don't really know what a typical workload would look like so it wouldn't be straightforward to do so. |
1af3ae4 to
f206ee1
Compare
795a8d3 to
50f1c9d
Compare
50f1c9d to
35c1f5e
Compare
|
/remove |
|
View all feedbacks in Devflow UI.
|

Description
This PR makes our PyTorch integration create profiles that actually look like profiles. Previously, we would get events from the PyTorch Profiler, sample them, and report them without looking at their context. As a result, we would get a "flat flame graph" where every frame would be at the same level.
Results
Before my changes flame graphs are "flat"
After my changes flame graphs are flame graphs (note: different code being profiled)
Live example profile (while
stocksretention lasts!)Details
The previous flame graph was obtained by profiling the following script.
Performance
Note this theoretically comes at a performance cost, as we need to reconstruct the event parent tree. However, looking at a Python profile for the Profiler (convenient that our Profiler is written in Python!)
The top lines are
events = prof.events()-- this line hasn't changed and used to be called as much as it is today.self_cpu_time: int = e.self_cpu_time_total-- this is new but is already more than 10x less CPU-intensive than 1.handle.push_frame(parent.name, _FILE_PLACEHOLDER, 0, 0)-- this is not new and not called more often than it used to behandle.flush_sample()-- this is not new and not called more often than it used to behandle.push_frame(f"PYTORCH_{device_type_str}", _DEVICE_FRAME_FILE_NAME, 0, 0)-- this is not new and not called more often than it used to beIn short, the most resource-hungry functions on the PyTorch Profiler at the moment are functions that already were there before, and that already were CPU-hungry before.
The added logic (to reconstruct the tree) is practically irrelevant as far as performance goes.
Related work
New prof-correctness check: DataDog/prof-correctness#152